OneData方法论在XX的实践

点击上方“蓝字”关注我吧！

#本文参考：美团OneData建设探索之路

1

背景

由于前期缺少规划，随着集团业务发展，暴露的问题越来越多，给数据治理工作带来了很大的挑战，在数据仓库建设过程中，主要发现了以下几个问题：

• 缺乏统一的标准，如：开发规范、指标口径等。

• 缺乏统一数据质量监控，如：字段数据不完整和不准确，数据发散等。

• 业务知识体系混乱，导致数据开发人员开发成本增加。

• 数据架构不合理，层级之间分工不明显，数据流向混乱。

• 缺失统一维度和指标管理。

2

目标

基于公司现有的数据平台，完善数据体系架构、数据规范、模型标准和开发模式，从而驱动业务快速发展

高人力成本、数据错误、浪费资源、杂乱无章、效率低下，这些经常出现的痛点，OneData都能轻松解决

1

核心思想

   从设计，开发和使用上保障规范和统一，实现数据资产全链路管理，提供标准的数据输出，包含数据规范定义，数据模型设计规范，ETL规范

2

核心特点

3

策略

3

应用

1

统一规范

数据来源于业务并支撑着业务的发展。因此，数仓建设的基石就是对于业务的把控。基于互联网行业的特点，基本上采用需求推动数据的建设，这也带来了一些问题，包括：数据对业务存在一定的滞后性；业务知识沉淀在各个需求里，导致业务知识体系分散。针对这些问题，我们提出统一业务规范，构建全局知识库，进而保障对业务认知的一致性。

设计统一规范

为了解决数据仓库建设过程中出现的各种痛点，我们从模型与规范两个方面进行建设，并提出设计统一规范。

1.模型

规范化模型分层、数据流向和主题划分，从而降低研发成本，增强指标复用性，并提高业务的支撑能力。

(1) 模型分层

优秀可靠的数仓体系，往往需要清晰的数据分层结构，即要保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长。结合这些原则及以往的工作经验，在数仓层面，我们将分层进行统一定义为四层：

(2) 模型数据流向

       重构之后，业务按照标准的数据流向进行开发，即ODS->DWD->DW->DWS->ADS。在保障了数据链路的合理性之后，又在此基础上确认了模型分层引用原则：

• 正常流向：ODS->DWD->DW->DWS->ADS，当出现ODS->DWD->DWS->ADS这种关系时，说明主题域未覆盖全。应将DWD数据落到DW中，对于使用频度非常低的表允许DWD->DWS。

• 尽量避免出现DWS宽表中使用DWD又使用（该DWD所归属主题域）DW的表。

• 同一主题域内对于DW生成DW的表，原则上要尽量避免，否则会影响ETL的效率。

• DW、DWS和ADS中禁止直接使用ODS的表， ODS的表只能被DWD引用。

• 禁止出现反向依赖，例如DW的表依赖DWS的表。

2.主题划分

• 面向业务：按照业务进行聚焦，降低对业务理解的难度，并能解耦复杂的业务。我们将实体关系模型进行变种处理为实体与业务过程模型。实体定义为业务过程的参与体；业务过程定义是由多个实体作用的结果，实体与业务过程都带有自己特有的属性。根据业务的聚合性，我们把业务进行拆分，形成了几个核心主题。

• 面向分析：按照分析聚焦，提升数据易用性，提高数据的共享与一致性。按照分析主体对象不同及分析特征，形成分析域主题在DWS 进行应用，例如用户分析域、订单分析域。

3.规范

模型是整个数仓建设基石，规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，我们统一按照最详细、可落地的方法进行规范建设。

(1) 词根

词根是维度和指标管理的基础，也是表字段命名的参考

(2) 表命名规范

通用规范

• 表名、字段名采用下划线分隔词根（consultorder->consult_order）

• 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义。

• 表名、字段名需以字母为开头。

• 表名、字段名最长不超过64个英文字符。

• 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期Review新增命名的不合理性。

• 在表名自定义部分禁止采用非标准的缩写。

表命名规则

ods dwd层

• 建表表名一律小写

• 表名命名规则： [层次].[业务]_[表内容]_[周期+处理方式]

dw dws层

• 建表表名一律小写

• 表名命名规则： [层次].[主题]_[表内容]_[周期+处理方式]  主题在dw层以后，表内容 参考业务系统表名，做适当处理，分表规则可以没有

  如：wedw_ods.test_order_info_df

  wedw_ods表示层次，test表示主题，order_info表示表内容，d表示周期(天)，f表示处理方式(全量抽取)

• 临时表命名规则：[层次].tb_目标表名_程序开始执行时间_序号

(3) 指标命名规范

结合指标的特性以及词根管理规范，将指标进行结构化处理。

A. 基础指标词根，即所有指标必须包含以下基础词根：

B.日期修饰词，用于修饰业务发生的时间区间。

C.聚合修饰词，对结果进行聚集操作。

D. 基础指标，单一的业务修饰词+基础指标词根构建基础指标

E. 派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性.

F.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。

G.日期类型指标命名规范，命名时要遵循：业务修饰词+基础指标词根+日期修饰词/聚合修饰词。将日期后缀加到名称后面，

H.聚合类型指标，命名时要遵循：业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面，

2

统一输出

数仓建设不仅仅是为了数据内容而建设，同时也为了提高交付的数据质量与数据使用的便利性。所以我们交付出去的数据必须是符合标准的高质量的数据，必须做到准确性，完整性，关联性等标准

数据质量满足以下几点是可以进行输出的

1. 数据资产管理

针对如何解决数据质量中维度与指标一致性以及如何提高数据易用性的问题，我们提出数据资产的概念，借助公司内部平台工具“大数据平台”实现了整个数据资产管理，它的功能如下图所示：

借用大数据平台，我们实现了：

• 统一指标管理，保证了指标定义、计算口径、数据来源的一致性。

• 统一维度管理，保证了维度定义、维度值的一致性。

• 统一维表管理，保证了维表及维表主键编码的唯一性。

• 统一数据出口，实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。

3

成就

3.3.1优化开发流程

我们对开发过程进行梳理，服务于整个OneData体系。对需求分析、指标管理、模型设计、数据验证进行了改善，并结合OneData模型策略，改善了数仓管理流程。

1. 需求分析：明确口径，评估排期，需求正规流程提交

2. 指标管理：完善指标命名规范，指标同名同义，指标与业务强相关，明确指标构成要素

3. 模型设计：完善开发流程规范，标准化业务调研，知识库文档集中管理，建立模型评审机制

4. ETL开发：ODS->DWD->DW->DWS->ADS 

5. 数据验证：制定数据测试标准

6. 任务调度：规范化调度参数配置

7. 上线管理

3.3.2资产管理列表

基于数据平台形成的资产管理体系，如下图所示：

4

总结

结合阿里的onedata方法论，我们构建了稳定成熟的基础数据仓库，并且从数据底层保证了数据质量，形成了我们自己的onedata理论体系

未来，我们还将在内部引入flink，clickhouse等技术，搭建实时数仓，满足灵活多样，低延迟的数据分析

在后续数仓维护过程中，不断地发现问题、解决问题和总结问题，保障数据稳定性、一致性和有效性，为核心业务构建价值链，最终形成企业级的数据资产。